Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000003_owner-urn-ietf _Fri Aug 2 17:50:18 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA26840 for urn-ietf-out; Fri, 2 Aug 1996 17:50:18 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA26835 for <[e-mail]>; Fri, 2 Aug 1996 17:50:14 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA08372  (mail destined for [e-mail]); Fri, 2 Aug 96 17:50:12 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA09114; Fri, 2 Aug 1996 15:50:09 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 02 Aug 1996 15:54:59 -0600
To: Lewis Girod <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] re NAPTR, URN-res-req
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Lewis Girod (at least at 07:22 PM 8/1/96 -0400)
>At 12:32 PM 7/28/96 PDT, Terry Allen wrote:
>
>>Much is made here of "hints,"
[...]
>It should be stated, however, that we were not
>intending hints to solve the sorts of semantics-oriented search
>problems you describe; we see this as a higher level of the problem
>that should be kept separate from the straight URN->document(s)
>mapping problem.

This is a useful clarification, thanks Lewis.


>>[...] ignores the power of supplying as input into the URN resolution
>>system ancillary information about the URN (hints in reverse, so to speak).
>
>[...]As for the idea of `hints in reverse', the URN community
>should decide if this is within the scope of our problem or whether we
>want to declare it outside.  My opinion is that it is outside; it
>widens the problem and makes the primary technique for resolution
>(i.e. precomputed lexical generalization of URNs) impossible.

I guess I thought that one way that unofficial hints could
get into the system was by direct injection by users. I think
it is certainly outside the scope of NAPTRs, but is something to
keep in mind for the future. There might be a ComMentor-style
annotation set that was user-supplied resolution hints.

>Under such a
>system, [the canonicalization proposol for an alternative to regexps]
>a name scheme designer can enforce certain policies about the
>format and semantics of the names under that scheme, whereas according
>to the original NAPTR model the top-level name scheme design had no
>impact on the structure underneath.

Something I left out of my previous message (hard to believe I left
anything out, I know :-)...
One of my concerns about the canonicalization proposal was that
a single program at the namespace level could not deal with constructed
names. How about allowing that program to insert a marker into the
canonical form of a name. When the client sees the marker, it means
that it would be legal for the incoming NAPTR to provide a program
for dealing with the rest of the URN. This way we get the restrictions
on permissable behavior that you want and can still handle constructed
names, which I think will become an important thing to do.

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"